As we are looking forward to year 2000 and beyond, a question arises. How will computing look in the future? The trends we have seen are obvious; more powerful chips are being released every few months, while software development struggles to keep up with the hardware but never does. Of course, we now have a slightly new twist, i.e. the new found popularity of internet, the web, and Java.RTM. code (developed by SUN.RTM.). For instance, with respect to the web, typically a server downloads code (e.g. graphics, Java applets) to a general purpose computer, and the computer's browser software interprets the codes for display. However, interpreting and downloading the code takes significant time.
Some have said that Java (being platform independent) has finally brought a tool to the computer market to break the major chip and operating system (OS) dominance which have developed in the desktop industry, via Intel.RTM. and Microsoft.RTM., respectively. However, different software vendors are creating their own Java extensions, such that Java is losing its portability. For example, Microsoft has developed its own Java interpreter, MS J++.RTM. with extensions specific to the Microsoft web browser Explorer.RTM. and other related Microsoft technology, such as Active-X.RTM..
Further, we have seen neither Intel nor Microsoft despair about web development, i.e., they do not see the currently available internet technologies as able to threaten their respective monopolies, as "Intel Inside" will continue to power general purpose PCs and Microsoft's OSs will continue to manage them, while its Microsoft web-browser Explorer.RTM. now supports Java code. Further, Microsoft's proprietary Active-X technology is a Java competitor which may yet derail the industry's effort to use open standards. Accordingly, Intel's and Microsoft's dominance remains the same.
It has been predicted that computing, especially network computing, will change so drastically in the near future that no company/vendor would be able to dominate any market but the current efforts by many software vendors to "extend" the Java standards is putting that prediction in doubt. As Java applets get developed, incorporating non-standard extensions will eventually cause the emergence of another yet another dominant Java applet supplier. At this point, there is little doubt it is going to be the current software giant Microsoft. By modifying its proprietary operating systems, like Windows 96 and Windows NT to more effectively process either Java applets or Active-X objects, Microsoft once again will dominate software application development.
General purpose computing on the desktop, i.e., desktops having a standard OS (such as Windows 95.RTM.) and a microprocessor (such as the Pentium.RTM. chip), has to be replaced by a system which is less expensive to own and maintain but at the same time does not short-change the user by taking away features which we all have come to expect from our PCs, such as flexibility, extendibility, high-security, ease-of-use, and reasonable cost of initial ownership to enable the software and hardware industry to proceed forward in new and creative ways.
Foreseeable disadvantages of the standard general purpose PC, with respect to the networks and Java, include the following. Java applications will increase in complexity, therefore requiring faster processors and greater memory in the desktop unit to run them (the same problem which PCs have always had) again forcing the user into a never-ending spiral of hardware and software upgrades. Currently, Java applets are four to five times slower than compiled code, requiring more powerful processors to get similar performance as compared to an application that runs native binary code. Further, converting applications from another high-level language to Java (or even from C++) is a very expensive, labor-intensive effort, so that it is no wonder that legacy COBOL applications are still often used in business.
It is also a concern that the computer's writable resources, e.g. a hard drive, can be compromised or damaged by rogue Java applets. On the other hand, if the computer has no writable resources, then the user typically keeps his or her files in remote locations, e.g. on a remote file server, thereby making the user's data files a security risk which no company can afford. An example of a computer having no writable resources is the proposed Network Computer "NC" (a joint effort by Apple.RTM., Netscape.RTM., IBM.RTM., Oracle.RTM. and SUN.RTM.).
A typical network system having server-client architecture, which can be utilized in the present invention, is illustrated in FIG. 1. In FIG. 1, network 10 includes a central server 7 connected to a plurality of clients 5 over a shared transmission medium 8. Network 10 is applicable to supporting the transmission of data on a local area network (LAN) or on a wide area network (WAN).
A typical server 7 may vary substantially in its architecture. It may be a unior multi-processor machine, a PC or a mainframe, a workstation from a major manufacturer or a proprietary technology based computer, etc. It may even be a special function device without any OS or software. Server 7 should be able, however, to function in a predefined way or to run whatever software that the company which owns the server needs to run on it. It should also be able to comply with standard transport protocol, such as tcp/ip used by the internet or other transport protocols used on wireless or wired LANs.
Server 7 may have its own file system for storing service-related files and data or server 7 may strictly be a computational server whose software is loaded from the file system of another server, i.e., a file server or file system of super-client (neither shown), which is preferable for security reasons. If the computational server runs the booted programs solely from RAM, then it would not have access to its local file system after the software is loaded into its main memory (RAM).
FIG. 1 illustrates the so called two-tier computing configuration. In addition, a three- or N-tier computing configuration may also be utilized, as will be discussed hereinlater.
Conventionally, in a first major configuration, the client stations 5 are essentially "dumb" terminals connected to a central server 7 via transmission medium 8. The central server contains the client users' data and the application/program code. Further, the central server executes all the programs for its clients 5.
Substantially all of the application logic (i.e., presentation logic, business logic, and database logic) is resident within the central server. Such application logic (presentation, business, database) includes any program logic concerned with delivering and/or executing the application service. Note, however, that each client may harbor some low-level graphical interface logic such as X11 protocol. These clients are diskless and perform no general computational tasks. Further, the database (file system) logic on the server is shared among the clients. An example of such a system is a set of X-terminals attached to a central server.
In a second major configuration, the central server 7 contains both the program code and the file system which the clients use, as with the first configuration, but does not execute any applications. Instead, the applications are downloaded into each requesting client 5 through the network and run on each client. The client, however, continues using the central server as the client database/file system source. The clients in this configuration are usually diskiess but do contain powerful CPUs, such as by SPARC.RTM., MIPS.RTM. and ALPHA.RTM.. Although all of the presentation, business and database logic (while running) reside on the client, the file system is located on the central server and is shared among the clients. An example of the second configuration include a LAN with a central database such as ORACLE, Informix or Sybase running on an IBM AS/100 file server and set of diskless desktop machines like SUN or RS6000 workstations using a central file server to get their program code and data.
Further, the proposed NC is similar to the second configuration, except that instead of loading native machine code onto a client, Java code is sent to be either interpreted or compiled on-the-fly into native code at the client station. That is, the Java code is either interpreted by the browser software on the client or the browser first compiles the Java code, then runs it. The obvious problems with this solution are that interpreted code and compilation is slow, and as the complexity of Java code increases, the CPU/memory combination of the NC or general purpose PC/browser combination would also have to increase in computational power and memory size to accommodate the growth. Further, Java code would arrive to the desktop in source form making it very difficult to determine whether malfunctions or bugs are associated with the Java applet or the browser software itself.
In addition, since the Java code is supplied to run on the client, an application foreign to the client is accepted which may potentially damage the PC's writable resources by malice or mistake (e.g., by utilizing security holes in the browsers). Further, the NC fails to protect the user's private data from other clients since it lacks local storage and all client data has to reside in a central location. Java also makes copyright enforcement an extremely difficult task for the software vendors. Since Java applets have absolutely no protection from being copied by the client/user machine, as they are delivered in source form.
In a third configuration, a three- or N-tier computing network is employed. Such a configuration is currently being utilized by Forte Technologies. They offer programming tools to decompose client-server applications into presentation logic which runs on each client 5, business logic which runs on the central server 7 and database logic which runs on a file server (not shown). However, the business and database logic may run on the same physical server. As with the first and second configurations, the client's database/file system logic is stored remotely from the client, as it is shared among the clients, and thus poses a security risk. Since the presentation logic runs on the client, this system is also faced with the problem of constant upgrades and high maintenance costs of the client stations. Another great problem in this model is that application codes have to be written specifically to one software vendor's implementation of the N-tier network and a user is typically forced to license and distribute parts of the system to run his own applications.
It is therefore an object of the present invention to overcome the disadvantages of the prior art.